Содержание

1.Что такое «BPMS»……………………………………………………………1

2. Задачи, которые решают системы класса «BPMS»………………………..7

3 Анализ Oracle BPA Suite, основанное на платформе ARIS ………………..15

3.1 Назначение и состав решения Oracle BPA Suite ……………….16

3.2 Oracle Business Process Architect …………………………………18

3.3 Oracle Business Process Simulator …………………………………19

3.4 Oracle Business Process Publisher …………………………………20

3.5 Oracle Business Process Server …………………………………….21

3.6 Реализация процесса в Oracle JDeveloper и его развертывание ..31

4 Заключение…………………………………………………………………..32

Список используемой литературы…………………………………………33

Внимание!

Это ОЗНАКОМИТЕЛЬНАЯ ВЕРСИЯ работы №3451, цена оригинала 1000 рублей. Оформлена в программе Microsoft Word.

ОплатаКонтакты

1.Что такое «BPMS».

BPMS (Business Process Management System) — система управления бизнес-процессами. Используются также термины BPM-система и просто BPM.

Основная идея BPM-системы предельно проста:

Берем описание бизнес-процесса (наподобие тех, что давно и успешно создаются специалистами по реинжинирингу бизнес-процессов) и отслеживаем его выполнение при помощи специализированной компьютерной программы.

Традиционный способ автоматизации бизнес-процессов — разработка или приобретение готового прикладного программного обеспечения. Однако на практике прикладные программы автоматизируют только часть шагов бизнес-процесса, а главное — внесение даже небольших изменений в схему бизнес-процесса означает необходимость перепрограммирования и большие затраты времени. В результате прикладные программы не успевают обновляться в том темпе, который диктуют изменяющиеся условия бизнеса и потребности самого предприятия. Изначально BPM-системы появились как решение именно этой конкретной проблемы.

Суть BPM-решения заключается в том, что бизнес-процесс описывается на языке, который может непосредственно исполняться специализированной программой.

Составные части BPMS

Типичная BPM-система состоит из стандартного набора компонент, соответствующих хорошо известным стадиям жизненного цикла бизнес-процесса: проектированию, исполнению, мониторингу.

Проектирование

Под проектированием понимается разработка схемы бизнес-процесса. В состав BPM-системы обычно входят:

1. графический дизайнер для рисования схемы бизнес-процесса

Advertisement
Узнайте стоимость Online
  • Тип работы
  • Часть диплома
  • Дипломная работа
  • Курсовая работа
  • Контрольная работа
  • Решение задач
  • Реферат
  • Научно - исследовательская работа
  • Отчет по практике
  • Ответы на билеты
  • Тест/экзамен online
  • Монография
  • Эссе
  • Доклад
  • Компьютерный набор текста
  • Компьютерный чертеж
  • Рецензия
  • Перевод
  • Репетитор
  • Бизнес-план
  • Конспекты
  • Проверка качества
  • Единоразовая консультация
  • Аспирантский реферат
  • Магистерская работа
  • Научная статья
  • Научный труд
  • Техническая редакция текста
  • Чертеж от руки
  • Диаграммы, таблицы
  • Презентация к защите
  • Тезисный план
  • Речь к диплому
  • Доработка заказа клиента
  • Отзыв на диплом
  • Публикация статьи в ВАК
  • Публикация статьи в Scopus
  • Дипломная работа MBA
  • Повышение оригинальности
  • Копирайтинг
  • Другое
Прикрепить файл
Рассчитать стоимость

2. репозиторий для ее хранения и организации совместного доступа

Возможность моделировать бизнес-процесс при помощи графического редактора является принципиальной особенностью BPM-систем: проектирование бизнес-процесса должен выполнять бизнес-аналитик без участия программиста.

Процедура создания модели бизнес-процесса мало чем отличается от привычной для бизнес-аналитиков процедуры рисования схем. Нарисовать шаги, описать бизнес-логику, определить группы пользователей и перечень вводимых на каждом шаге реквизитов.

Рисунок 1.1

Результат сохраняется на сервере, после чего процесс может быть инициирован. При необходимости в схему можно вносить изменения, также, не прибегая к помощи программистов. Альтернативно, схема бизнес-процесса может разрабатываться в каком-либо из традиционных средств моделирования бизнес-процессов и переноситься в BPM-систему при помощи импорта-экспорта.

Исполнение

Ядром BPM-системы является его «движок» (BPM Engine). Он стартует экземпляры бизнес-процессов, отслеживает смену их состояний, хранит значения реквизитов, выполняет бизнес-правила. Если сравнить схему бизнес-процесс с нотами, игра по которым производит приятную для слуха мелодию, то BPM Engine — это механическое пианино, играющее по этим нотам.

Ядро BPM-систем предоставляет также интерфейсы для стыковки с внешними приложениями — специальные адаптеры, вебсервисы, драйверы для доступа к реляционным базам данных или к другим источникам данных. Использование этих интерфейсов зависит от типа бизнес-процесса:

1.Относительно небольшую долю составляют бизнес-процессы, которые BPM-система может выполнить полностью автоматически, запустив ряд специализированных программ. Например, интернет-провайдер при активации нового клиента должен создать для него учетную запись на сервере, добавить информацию в системную службу имен, в конфигурационные файлы веб-сервера и электронной почты и наконец, сформировать счет и отправить его пользователю вместе с уведомлением об активации сервиса. Каждая операция выполняется отдельной программой (в идеале через стандартизованный интерфейс — вебсервис), а BPMS играет роль планировщика.

2.Наиболее распространен тип бизнес-процессов, предполагающий как стыковку со специализированными приложениями, так и участие живых людей. Например, сотрудник финансового отдела должен зарегистриро-вать факт оплаты в ERP-системе как шаг бизнес-процесса реализации то-вара. Этот сценарий требует разработки интерфейсных программ, рабо-тающих и с контекстом бизнес-процесса (т.е. с его реквизитами), и с внешней прикладной программой или базой данных. В контексте бизнес-процесса сохраняются ссылки — номер платежки, код контрагента — по которым развернутую информацию можно извлечь из внешнего приложения или базы данных на следующих шагах бизнес-процесса. Разработка таких комплексных приложений обычно — самая трудоемкая часть проекта BPM.

3.Наконец, существуют шаги бизнес-процессов, автоматизировать которые невозможно или слишком сложно. (Например, бизнес-процесс может включать рытье канавы — ясно, что это задача не для компьютера.) В такой ситуации BPM-система подаст пользователю сигнал о том, что ему поручено определенное задание, и будет ждать от него подтверждения о выполнении.

Ключевой элемент интерфейса пользователя BPM-системы — т.н. «персональный список задач», перечень шагов запущенных экземпляров бизнес-процессов, назначенных данному конкретному пользователю или ролевой группе, к которой он принадлежит:

Рисунок 1.2

Благодаря такой организации работы исполнителю за компьютером не приходится думать, с какой функцией и какого именно внешнего прило-жения ему пора работать: он видит перечень назначенных ему заданий, и когда он берет очередное задание себе на исполнение, нужная программа запускается автоматически.

BPM-системы предоставляют доступ через веб-интерфейс, что позволяет максимально легко вовлекать в коллективную работу сотрудников территориально удаленных подразделений и организаций-контрагентов.

Мониторинг

BPM-система осуществляет контроль бизнес-процессов двумя путями:

Менеджеру не приходится выяснять «на ком стрелка» — для каждого экземпляра бизнес-процесса это наглядно показывает динамически формируемое графическое изображение. Например, вот как может выглядеть графическое изображение экземпляра процесса, схема которого рассматривалась выше.

Зеленым цветом отмечены шаги процесса, которые выполняются в данный момент; в рассмотренном примере параллельно выполняются два шага, один из которых соответствует основной последовательности работ, а второй служит для контроля процесса его инициатором. Красные стрелки показывают пройденный маршрут.

BPM-система накапливает ценную статистику о параметрах выполнения экземпляров бизнес-процессов: интенсивность (число экземпляров в неделю или месяц), продолжительность (время от запуска до завершения), нагрузка на отдельных специалистов (число и продолжительность выполненных заданий).

Рисунок 1.3

BPM-системы, как правило, предоставляют базовый набор отчетов по показателям бизнес-процессов. На их основе могут быть сконструированы т.н. «ключевые показатели эффективности» (KPI, Key Performance Indicators), которые, в свою очередь, могут быть увязаны с «системой сбалансированных показателей» (BSC, Balanced Scoreсard).

2. Задачи, которые решают системы класса «BPMS»

BPM-системы иногда рассматривают как разновидность систем докумен-тооборота и как технологию интеграции корпоративных приложений. И тот, и другой взгляд имеют под собой некоторые основания, но основное назначение BPM-систем — управление бизнес-процессами.

Бизнес-процессы

Определение бизнес-процесса, которое дает один из авторов концепции реинжиниринга бизнес-процессов Майкл Хаммер:

Бизнес-процесс — это организованный комплекс взаимосвязанных действий, который в совокупности дают ценный для клиента результат.

В зависимости от контекста, термин бизнес-процесс может означать и метод, технологию в приведенном выше смысле, и конкретный, протекающий «здесь и сейчас» процесс, например, заказа продукции клиентом. Там, где необходимо подчеркнуть разницу между этими понятиями, для них используются соответственно термины схема или описание и экземпляр бизнес-процесса.

Бизнес-процесс иногда называют технологией — технологией получения коммерческого результата. При этом подчеркивается повторяемость: требуемый результат неукоснительно вытекает из заданных предусловий при соблюдении установленной процедуры.

Но бизнес-процесс — это больше, чем просто следование установленной процедуре. Строгое определение бизнес-процесса, данное выше, требует, чтобы процедура эта была оптимизирована на удовлетворение потребности клиента. Если работа на предприятии (включая систему стимулирования) организована так, что работники, менеджеры, отделы преследуют свои узкие цели и никто из них не беспокоится о достижении нужного клиенту результата, то это значит, что основная идея бизнес-процессов данным предприятием не усвоена.

Концепция бизнес-процесса

Исторически концепция бизнес-процесса появилась как ответ на органические недостатки управления, организованного по функциональному признаку. Традиционно управление предприятием делится на функциональные области, за которые отвечают отделы: бухгалтерия, финансы, снабжение, продажи, производство и т.д. Фундаментальная неэффективность такой системы обусловлена тем, что в ней каждый преследует цели личные или своего подразделения и никто не нацелен на конечный результат — удовлетворение потребности клиента.

Иллюстрация проблем, возникающих в такой системе, на каноническом примере процесса продажи товара:

отдел продаж стремится максимально снизить цену и сроки, чтобы убедить клиенты купить товар и выполнить свой план по продажам

технологи, поставленные перед фактом подписанного договора, говорят что произвести товар с заданными в спецификации характеристиками или в установленные контрактом сроки невозможно

бухгалтерия извещает руководство, что данная сделка будет убыточной, потому что прописанная в контракте цена ниже себестоимости

Подобные проблемы, конечно, решаются, но только непрекращающимися усилиями менеджмента. Управление на основе бизнес-процессов — это путь к решению их на системной основе. Бизнес-процессы призваны «сломать стены между отделами» и подчинить деятельность предприятия главным, а не локальным целям.

Схемы бизнес-процессов — это особо ценная форма интеллектуального капитала компании. Но, как показал опыт 90-х годов, накопление его идет слишком медленными темпами и обходится слишком дорого.

Проблемы реинжиниринга бизнес-процессов

Теоретически внедрить бизнес-процесс можно двумя способами: либо разработав его «с чистого листа», либо критически переработав существующую практику. Первому подходу соответствует английский термин engineering (конструирование), второму — re-engineering (повторное конструирование, перестройка).

Потребность в технологиях ведения бизнеса проявляется по мере взросления и роста компании; пока компания состоит из нескольких увлеченных основателей и производит уникальный продукт и услугу, бизнес может быть «кустарным». Поэтому интерес к бизнес-процессам в первую очередь проявляют зрелые компании, работающие в стабильных отраслях. А для таких компаний возможен только путь перестройки уже существующей практики, отсюда — устойчивое словосочетание «реинжиниринг бизнес-процессов».

Реинжиниринг бизнес-процессов подразумевает вполне определенную последовательность шагов:

Анализ существующей бизнес-практики, на жаргоне реинжиниринга он называется составлением схемы «as-is» («как есть»).

Проектирование оптимальной схемы бизнес-процесса, называемой «to-be» («как будет»).

Планирование и фактический переход от первого ко второму.

Хотя существует ряд впечатляющих примеров успеха компаний, ради-кально перестроивших схему своих операций на основе бизнес-процессов, проекты реинжиниринга сопряжены с большими затратами и высокими рисками. По некоторым оценкам, доля удачных проектов реинжиниринга составляет всего 30%, причем в самом тяжелом случае неудача проекта может привести к краху компании.

Характерные проблемы из практики (в том числе отечественной) реинжиниринга бизнес-процессов:

Потеря фокуса

Среди консультантов по бизнес-процессам широко распространен т.н. «системный подход». Заключается он в том, что на первом листе рисуется прямоугольник с надписью «наше предприятие», который затем последовательно детализируется на все более мелкие процессы и подпроцессы.

Проблема в том, что, во-первых, такая декомпозиция зачастую сводится к делению по функциональным подразделениям. Так появляются, например, «бизнес-процессы финансового отдела». Очевидно, что такой подход полностью выхолащивает исходную концепцию бизнес-процесса, воспроизводя функциональную организацию управления.

Во-вторых, результатом такого анализа являются тысячи бизнес-процессов и, на нижнем уровне, десятки тысяч операций. Но в любом бизнесе есть не больше десятка бизнес-процессов, определяющих его успех. И усилия надо фокусировать на них, а не распылять между множеством процессов, не являющихся критичными.

Неустранимый разрыв между «as-is» и «to-be»

Концепция классического реинжиниринга, по сути, есть концепция «большого скачка». Вы должны тщательно все взвесить, спланировать и, собрав волю в кулак, внедрить радикально новый бизнес-процесс.

Из-за высокой ответственности такого шага его планирование занимает очень много времени (по принципу «семь раз отмерь, один отрежь»). В сочетании с особенностями упомянутого выше «системного подхода» это приводит к тому, что результаты анализа устаревают быстрее, чем он заканчивается. Устаревают из-за того, что за месяцы, ушедшие на «as-is» и «to-be» анализ и на планирование перехода, успевает поменяться бизнес-окружение, представление самого бизнеса об оптимальном бизнес-процессе, а зачастую успевает смениться и собственник бизнеса.

Можно задать вопрос: а что мешает проводить реинжиниринг поэтапно? Проблема в том, что изменение бизнес-процесса — дорогостоящее меро-приятие: надо переобучить сотрудников и менеджеров, обновить должностные инструкции, выполнить доработки или перенастройку корпоративной информационной системы. Проходить через все это, конечно же, лучше один раз.

Инструмент непрямого действия

Среди бизнес-консультантов имеет хождение фраза: «мы даем вам реше-ние, реализация — это ваша проблема».

Применительно к реинжинирингу это означает, что результатом деятельности приглашенных специалистов зачастую является солидный отчет с множеством «картинок», которые вдобавок (по указанным выше причинам) в значительной степени уже устарели. С этого момента предприятие, получившее «решение», как правило остается один на один с проблемой: как претворить его в жизнь?

Консультант по реинжинирингу вооружен программой для моделирования бизнес-процессов, которая, в отличие от BPM, позволяет только рисовать схемы, но не управлять бизнес-процессами.

BPMS как решение проблем реинжиниринга.

BPM-система эффективно решает перечисленные выше проблемы:

1) На выходе — не «картинки», а работающая система.

BPM-проект нацелен на конечный результат — внедрение бизнес-процесса; в нем невозможна подмена конечного результата промежуточ-ным — рисованием множества пусть правильных, но самих по себе бесполезных схем.

2) Схема бизнес-процесса в BPM предельно конкретна.

BPM нацелен на автоматизацию конкретных, критичных для бизнеса процессов, а не на составление всеобъемлющей картины жизни предприятия. Процессы, попадающие в фокус, моделируются не «примерно», а очень точно.

3) BPM — средство изучения бизнес-процессов.

BPM радикально сокращает время и затраты на внедрение бизнес-процессов. Благодаря этому появляется возможность оптимизировать бизнес-процесс не «большим скачком», а последовательно, в несколько этапов. Бизнес-процесс внедряется в кратчайшие сроки, так, как он видится вначале. Затем, по мере выявления и осознания расхождений со сложившейся практикой или требованиями бизнеса, в него вносятся изменения. Благодаря тому, что BPM — средство прямого управления бизнес-процессами, изменения не приходится проводить в жизнь через переобучение, изменение должностных инструкций и т.п.

4) Непрерывный реинжиниринг собственными силами.

BPM позволяет постоянно поддерживать схему бизнес-процесса в акту-альном состоянии. Если изменение бизнес-окружения или внутренних требований бизнеса диктует изменение схемы бизнес-процесса, то такие изменения оперативно вносятся в BPM-систему. Правила могут меняться и меняются, но никакие операции не выполняются в обход них. Важно, что изменения в схему бизнес-процесса под силу вносить собственным специалистам предприятия, для этого не требуется ни программистская квалификация, ни глубокие теоретические познания.

Различие подходов суммируются в следующей таблице:

Традиционный реинжиниринг Автоматизация бизнес-процессов при помощи BPMS

тотальное моделирование всех бизнес-процессов, про-ектирование сверху-вниз первоочередное внимание кри-тичным для бизнеса процессам, объектное проектирование

длительный цикл разработки, оп-тимизация «большим скачком» короткий цикл разработки, по-этапная оптимизация

схема бизнес-процесса актуальна только в момент сдачи работы внешними консультантами постоянное поддержание схем бизнес-процессов в актуальном состоянии

средства автоматизации только для анализа бизнес-процессов средства автоматизации для ана-лиза, исполнения и контроля биз-нес-процессов

Преимущества BPM в значительной степени обусловлены радикальным сокращением затрат и сроков по сравнению с традиционной разработкой. Соответственно, важный критерий при выборе BPMS — это то, насколько быстро та или иная система позволяет разработать и инсталлировать схему бизнес-процесса и интерфейсные веб-приложения, состыковать бизнес-процесс с внешними приложениями.

Системы документооборота

Системы управления документооборотом исторически развивались от отслеживания местонахождения и состояния документов к поддержке совместной работы над документами, составлению и контролю маршрутов их движения. В сегодняшних ECM-системах (Enterprise Content Management, управление корпоративным контентом) коллективную разработку и исполнение документов обеспечивают модули Workflow.

Области применения BPM-систем и модулей Workflow ECM-систем близки, но не сводимы друг к другу: существуют бизнес-процессы, в которых документы отсутствуют или их роль мала, и наоборот, работа над документами возможна вне бизнес-процесса.

Кроме того, между ECM/Workflow и BPM есть существенные технологи-ческие и методические отличия:

ECM/Workflow BPM

ad hoc маршруты движения информации алгоритмизированные маршруты движения инфор-мации

неструктурированная информация (произвольные документы) структурированная информация (реквизиты, бизнес-объекты)

собственный контент ссылки на данные во внешних системах, базах, хранилищах

патентованные (proprietary) алго-ритмы, структуры данных, интер-фейсы системы, основанные на откры-тых стандартах

BPM как ответ на ограниченность систем документооборота

Типичные проблемы, с которыми сталкиваются предприятия и организации при внедрении систем документооборота:

Сложная и трудоемкая интеграция с корпоративными системами. Доку-менты «оборачиваются» сами по себе, а корпоративные системы живут сами по себе.

В процессе обработки документа содержащаяся в нем информация должна синхронизовываться с корпоративными системами и приложениями, такими как ERP, CRM, специализированные приложения (например, биллинговые системы). Системы документооборота, как правило, используют собственные, нестандартные интерфейсы, и для успешной стыковки нужен специальный адаптер к каждой внешней системе. На практике это вызывает серьезные затруднения. Более эффективный путь — использовать для интеграции стандартные интерфейсы, принятые отраслью в целом, а не отдельным поставщиком.

Ограниченная производительность и масштабируемость.

Там, где системы документооборота в своих применениях оказываются востребованными в масштабе предприятия и становятся критичными для бизнеса, им недостает производительности и масштабируемости. Пример проблемы такого рода — базы данных на плоских файлах, используемые в Lotus Notes, уступают реляционным базам данных по производительности и функциональности, что ограничивает масштаб применения этой платформы.

Обоим требованиям — открытости и масштабируемости — удовлетворяют BPM-системы, реализованные на платформе J2EE. Платформа J2EE основана на открытых, поддерживаемых лидерами ИТ-отрасли, стандартах, что способствует интеграции с корпоративными приложениями. Многоуровневая архитектура J2EE позволяет достигать высокой производительности и надежности за счет распределения нагрузки между серверами.

Интеграция приложений

Дилемма, постоянно стоящая перед пользователями информационных систем: что предпочесть, программные решения от одного доверенного поставщика («Single Vendor») или же набор решений, лучших каждое в своем классе программного обеспечения («Best of Breed»),— естественно, от разных поставщиков.

В разные годы баланс предпочтений пользователей смещался то в одну, то в другую сторону. Так, для 80-х годов была характерна «лоскутная автоматизация» — множество АРМов от разных поставщиков. К 90-м этот подход себя исчерпал и все поверили во всемогущество ERP: предполагалось, что, внедрив ERP-систему, предприятие удовлетворит если не все, то почти все свои потребности; соответственно, подход «Single Vendor» стал выглядеть более предпочтительным.

С опытом пришло понимание, что ERP — это еще не все. С другой стороны, и сама концепция ERP подверглась «урезанию». Сегодня, в зависимости от личных предпочтений того или иного вендора или автора, он может относить или не относить к ERP:

1 )ведение отношений с заказчиками (CRM — Customer Relations Management)

2) управление персоналом (HR — Human Resources)

3) бизнес-анализ и поддержка принятия решений (BI — Business Intelli-gence, DSS — Decision Support System)

4) бюджетирование и финансовое планирование (Performance Management, Budgeting, Forecasting)

5) оперативное управление производством (MES — Manufacturing Enter-prise System)

В результате, по оценке Gartner Group, сегодня ERP-система в среднем покрывает 40% потребностей предприятия против 70% в прошлом. Нынешние заказчики все меньше склонны ждать всеобъемлющего решения от одного поставщика и все больше внимания уделяют интеграции приложений.

Сервис-ориентированная архитектура

Для этого изменившегося ландшафта была предложена новая технология. Идея сервис-ориентированной архитектуры (SOA, Service-Oriented Architecture) — это не платформы и не протоколы, а стремление уйти от бесконечного переписывания программного обеспечения и от болезненной смены одной корпоративной системы на другую, еще более интегрированную и функциональную.

В самом деле, стоит ли переписывать модуль, например, подготовки сче-тов-фактур, из-за того, что система, в которую он входит, теперь будет включать CRM? Может быть вместо этого зафиксировать «достаточно хороший» модуль и наращивать функциональность, интегрируя модули каким-то другим способом, без переписывания?

Сервис-ориентированная архитектура как раз и указывает такой способ: нужно «обернуть» функции существующих приложений при помощи вебсервисов, превратив их тем самым в стандартные «строительные блоки», которые можно будет использовать самыми разнообразными способами. Управление последовательностью вызовов вебсервисов и передачей данных между ними называется «дирижированием вебсервисами» (Web Service Orchestration).

BPM-системы идеально вписываются в эту картину в качестве дирижера вебсервисов, а формулировка задачи интеграции корпоративных приложений получает логическое завершение: интеграция приложений на основе бизнес-процессов.

Уникальность вебсервисов как технологии интеграции в том, что она ак-тивно поддерживается как Microsoft, так и противостоящим лагерем сто-ронников Unix, Linux, Java. В результате вебсервисы — это наилучшая технология, для интеграции приложений Microsoft .NET и Java.

Однако, при всей перспективности SOA надо заметить, что повсеместный переход на эту архитектуру пока не состоялся. Если взять, например, 1С как наиболее распространенную в России корпоративную систему, то сегодня обратиться к ней через вебсервисы не удастся. Поэтому прагматичные вендоры BPM предлагают спектр интеграционных возможностей: вебсервисы, JDBC (Java DataBase Connectivity) для доступа к базам данных, JCA (Java Connection Adapters) для доступа к бизнес-объектам.

Бизнес-процессы и базы данных

В учебниках по базам данных в качестве примеров рассматривается статическая информация: перечни инвентарных объектов, контрагентов, сотрудников и т.п. Но опытные программисты знают, что сложность структуры базы данных и трудоемкость разработки возрастают на порядок, когда мы перестаем рассматривать эти данные как статические и начинаем отслеживать их изменения: переходы сотрудников с одного места работы на другое, передачи товаров по накладным, дооборудование и переоценка основных средств. Причем при бли-жайшем рассмотрении любой объект из статического становится динамическим, например, простая задача ведения административной структуры становится ведением организационно-штатной структуры.

Проблемы передачи и синхронизации данных возникают даже в рамках единой интегрированной системы. Например, прежде чем информация о новом месте работы сотрудника попадет в расчетный отдел, она существует в виде сначала проекта приказа, а потому утвержденного распоряжения в отделе кадров. Картина еще больше усложняется из-за того, что люди совершают ошибки, а значит, необходимо предусмотреть не только поступательное движение информации, но и возврат назад по цепочке для исправления допущенных ошибок.

Как правило, одна система не в состоянии удовлетворить потребности предприятия. Типичная картина: «большая» система играет роль информационного ядра и решает стандартные управленческие задачи, а специфичные для данного предприятия задачи автоматизируются небольшими программами собственной разработки. В этой ситуации разработчикам приходится прилагать еще большие усилия для синхронизации данных и упорядочивания взаимодействия систем.

BPM-системы, со своей стороны, нацелены на динамический аспект ин-формации, но не предназначены для хранения и обработки статических данных. Таким образом, технологии DBMS и BPMS органически допол-няют друг друга, а разработчики, освоившие и тот, и другой инструмент и интегрировавшие в свои системы и базу данных, и «движок» BPMS, могут добиться большего с меньшими усилиями и в сжатые сроки.

Появление BPMS как нового класса системного программного обеспече-ния по значимости сравнимо с появлением в начале 80-х коммерческих DBMS (СУБД) общего назначения. С появлением BPMS жестко зашивать схему конкретного бизнес-процесса в коды программы или использовать частные, нестандартные механизмы описания бизнес-процессов ERP-систем, стало столь же нерациональным, что и использование для хранения данных внешних файлов вместо СУБД.

3 Анализ Oracle BPA Suite, основанное на платформе ARIS

Как, наверное, уже известно уважаемым читателям, летом прошедшего года корпорация Oracle объявила о заключении с компанией IDS Scheer соглашения, в рамках которого Oracle выпустила решение Oracle Business Process Analysis (BPA) Suite, основанное на платформе моделирования бизнес-процессов IDS Scheer ARIS Platform. Указанный комплекс дополняет такие базирующиеся на стандартах BPM-продукты Oracle, как Oracle SOA Suite и Oracle BPEL Process Manager, и может развертываться вместе c приложениями Oracle и других поставщиков, предоставляя бизнес-аналитикам и архитекторам средства построения моделей, имитационного моделирования и публикации бизнес-процессов. При этом Oracle Business Process Analysis Suite и Oracle BPEL Process Manager оптимизированы для работы с решениями Oracle, включая ERP-системы Oracle E-Business Suite и Oracle PeopleSoft Enterprise, а также CRM-системы Siebel, и будут использоваться для моделирования и выполнения бизнес-процессов для нового семейства приложений Oracle Fusion Applications.

Применение решения Oracle Business Process Analysis Suite в компаниях, ис-пользующих решения на основе продуктов семейства Oracle Fusion Middleware, позволит ИТ-службам компаний быстрее реагировать на изме-нения в ее бизнес-процессах, поскольку данное решение может служить тем самым связующим звеном между потребностями бизнеса и поддержкой их на уровне информационных систем, которого зачастую не хватает во многих компаниях.

Решение Oracle Business Process Analysis Suite появилось на рынке осенью 2006 года. Настоящая статья посвящена возможностям этого продукта и принципам его применения и предназначена для ИТ-менеджеров и архитекторов приложений на базе Oracle Fusion Middleware.

3.1 Назначение и состав решения Oracle BPA Suite

Сейчас ни для кого не секрет, что процессный подход в управлении позволяет серьезным образом повысить конкурентоспособность, эффективность и гибкость предприятия, качество его продуктов и услуг. Эффективное управление бизнес-процессами, в свою очередь, требует применения средств их анализа и моделирования, интегрированного со средствами выполнения процессов, создания приложений и мониторинга выполнения. Именно таким средством и является решение Oracle BPA Suite. Назначением указанного решения является моделирование бизнес-процессов (включая имитационное моделирование), публикация моделей, генерация на их основе кода для выполнения его серверными приложениями, входящими в состав Oracle Fusion Middleware.

Важно отметить, что в качестве основы для решения Oracle BPA Suite была выбрана платформа IDS Scheer ARIS Platform, на сегодняшний день признанная ведущими аналитиками (такими как Gartner Group, Forrester) лидирующей в отрасли платформой для анализа и моделирования бизнес-процессов (рис. 1).

Рис.1. Ведущие производители средств анализа бизнес-процессов (Источник: Michael J. Blechar and Jim Sinur, Magic Quadrant for Business Process Analysis Tools, 2006 — Gartner RAS Core Research Note G00137850)

Перевод надписей:

Способность к реализа-ции Претенденты Лидеры

Нишевые иг-роки Провидцы

Полнота видения

В состав решения Oracle BPA Suite входят следующие компоненты: Oracle Business Process Architect, Oracle Business Process Simulator, Oracle Business Process Publisher и Oracle Business Process Server. Перечисленные компоненты позволяют осуществить все этапы управления бизнес-процессами, а именно, разработку стратегии управления процессами, опи-сание процессов, их последующий анализ и совершенствование, а также их регламентацию и последующее внедрение, включая их публикацию и реализацию их поддержки на уровне информационных систем, и их контроллинг (подробнее об этом можно прочесть в статье Светланы Беловой и Антона Шматалюка “Использование ARIS на этапе Контроллинга бизнес-процессов” в настоящем выпуске журнала).

Ниже мы рассмотрим назначение каждого из перечисленных продуктов.

3.2 Oracle Business Process Architect

Oracle Business Process Architect представляет собой не что иное как слегка модифицированное средство моделирования и анализа бизнес-процессов ARIS Business Architect 7.0 (рис. 2).

Рис.2. Oracle Business Process Architect

Указанное средство моделирования позволяет создавать различные типы моделей бизнес-процессов и ИТ-инфраструктуры с применением различных методологий и нотаций, выбор которых в данном продукте более чем исчерпывает потребности большинства компаний.

Говоря о моделировании и оптимизации процессов, отметим такие возможности этого продукта как автоматическая генерация моделей одного типа на основании моделей других типов, средства автоматической проверки целостности и корректности моделей, в том числе согласно определенным пользователем правилам, а также средства создания решений на основе данного продукта (например, инструментов генерации моделей на основе внешних данных или средств создания отчетов по самим моделям) с помощью встроенной в него среды разработки Java-кода и используемой этим кодом библиотеки классов, предоставляющей доступ ко всем данным, содержащимся в моделях. Впрочем, возможностям ARIS Business Architect (и, соответственно, Oracle Business Process Architect) посвящено достаточное количество статей в настоящем выпуске журнала, поэтому читатели, интересующиеся возможностями, отличными от связанных с интеграцией с продуктами семейства Oracle Fusion Middleware, могут обратиться к соответствующим публикациям). Об интеграции же Oracle Business Process Architect с продуктами семейства Oracle Fusion Middleware мы расскажем чуть позже.

3.3 Oracle Business Process Simulator

Oracle Business Process Simulator (модифицированная версия ARIS Simulation)– это средство осуществления имитационного моделирования сценариев процессов с целью выбора наиболее оптимальной модели, которая должна явиться результатом проектирования бизнес-процессов (подробнее о проектировании бизнес-процессов можно прочесть в статье Георгия Каменнова и Николая Ешича “Использование ARIS на этапе Проектирования бизнес-процессов” в настоящем выпуске журнала). Подобное моделирование позволяет существенно снизить ошибки проектирования процессов, поскольку позволяет оценить возможности разработанного процесса еще до реального его выполнения.

Отметим, что Oracle Business Process Simulator содержит развитые средства статистического анализа результатов моделирования и их визуализации (рис. 3).

Рис.3. Средства визуализации данных Oracle Business Process Simulator

3.4 Oracle Business Process Publisher

Oracle Business Process Publisher (модифицированная версия ARIS Web Publisher)– средство для публикации моделей процессов на Web-порталах, Интернет- и интранет-сайтах с целью предоставления доступа бизнес -пользователей к сведениям о моделях процессов. Чаще всего публикация моделей осуществляется либо непосредственно перед внедрением спроектированных бизнес-процессов с целью от пользователей предложений по внесению изменений, либо одновременно с внедрением, когда целью публикации является ознакомление пользователей с текущими бизнес-процессами компании (подробнее о внедрении бизнес-процессов можно прочесть в статье Антона Шматалюка “Использование ARIS на этапе Внедрения бизнес-процессов”).

Oracle Business Process Publisher интегрирован в Oracle Business Process Architect – публикация выбранных моделей для просмотра их пользователями с помощью Web-браузеров осуществляется непосредственно из этого приложения (рис. 4).

Рис.4. Результаты публикации данных с помощью Oracle Business Process Publisher

Отметим, что Oracle Business Process Publisher позволяет применять при публикации различные средства – от HTML-документов с внедренным кодом на скриптовых языках до Java-апплетов, предоставляющих более удобный пользовательский интерфейс по сравнению с HTML-интерфейсом. Подобный выбор средств позволяет публиковать модели независимо от того, каковы принятые в организации требования безопасности при настройке браузеров.

3.5 Oracle Business Process Server

Oracle Business Process Server (он же — ARIS Business Server) представляет собой middleware-продукт, предназначенный для поддержки коллективной разработки моделей процессов. Технологически платформа ARIS основана на трехзвенной архитектуре, состоящей из:

серверной СУБД (в качестве которой могут выступать в том числе и различные редакции СУБД Oracle 9i и Oracle 10i), управляющей базами данных, в которых хранятся модели,

middleware-сервера, являющегося, с одной стороны, клиентом указанной СУБД, а, с другой стороны, обслуживающим запросы клиентских приложений на выбор и изменение данных (это и есть Oracle Business Process Server);

клиентских приложений (включая Oracle Business Process Architect, Oracle Business Process Simulator, а также, в общем случае, Web-серверы для публикации моделей с помощью Oracle Business Process Publisher), которые обращаются к middleware-серверу, но не имеют непосредственного доступа к базам данных, содержащих модели.

Отметим, что даже при использовании локальной установки Oracle BPA Suite на один компьютер также применяется трехзвенная архитектура платформы ARIS – на таком компьютере будут присутствовать все три звена.

Назначение Oracle Business Process Server сходно с назначением большинства middleware-серверов подобного типа. Этот компонент платформы ARIS нужен для обеспечения централизованного управления данными, предоставления средств разграничения доступа к данным, отличных от предоставляемых самой СУБД (в данном случае – для реализации доступа к данным с применением концепции методологических фильтров, позволяющих предоставлять или запрещать доступ конкретного пользователя к определенным моделям и объектам) , а также управления целостностью и непротиворечивостью данных.

Создание SOA-ориентированных решений с помощью Oracle Business Process Architect и Oracle Fusion Middleware

SOA (Service-Oriented Architecture – архитектура, ориентированная на сервисы) — это подход к разработке программного обеспечения, основанный на использовании заменяемых компонентов, представляющих собой сервисы со стандартизированными интерфейсами, в общем случае расположенные в произвольных местах и доступные с помощью различных сетевых протоколов. Решения, разработанные в соответствии с принципами SOA, чаще всего (но не всегда) реализуются в виде набора Web-сервисов, интегрированных при помощи известных стандартных протоколов, таких как SOAP, HTTP, WSDL, и использующих их клиентов.

BPEL представляет собой язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. Он расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций. Спецификация BPEL была совместно создана компаниями BEA Systems, IBM и Microsoft.

Oracle Business Process Architect интересен не только как средство описания и анализа бизнес-процессов, но и как инструмент, применяющийся при их про-граммной реализации за счет интеграции с продуктами семейства Oracle Fusion Middleware. Этот продукт позволяет импортировать в среду моделирования имеющиеся описания процессов и наоборот, преобразовать модели процессов в описание в формате BPEL XML с целью использования его в средствах разработки, в частности, в Oracle JDeveloper, реализации соответствующего Web-сервиса и исполнения его с помощью Oracle BPEL Process Manager и Oracle Application Server, реализуя тем самым концепцию SOA — архитектуры, ориентированной на сервисы.

SOA (Service-Oriented Architecture – архитектура, ориентированная на сервисы) — это подход к разработке программного обеспечения, основанный на использовании заменяемых компонентов, представляющих собой сервисы со стандартизированными интерфейсами, в общем случае расположенные в произвольных местах и доступные с помощью различных сетевых протоколов. Решения, разработанные в соответствии с принципами SOA, чаще всего (но не всегда) реализуются в виде набора Web-сервисов, интегрированных при помощи известных стандартных протоколов, таких как SOAP, HTTP, WSDL, и использующих их клиентов.

BPEL представляет собой язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. Он расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций. Спецификация BPEL была совместно создана компаниями BEA Systems, IBM и Microsoft.

Ниже кратко будут рассмотрены основные действия, которые выполняются при осуществлении программной реализации бизнес-процессов, описанных с помощью Oracle Business Process Architect, а именно, моделирование процесса, добавление к модели ссылок на имеющиеся Web-сервисы, генерация BPEL-описаний процесса, реализация его с помощью Oracle JDeveloper и развертывание готового процесса с применением Oracle Application Server и Oracle BPEL Process Management Server.

Создание модели процесса, подлежащего реализации

При описании и совершенствовании процессов описание деятельности компа-нии осуществляется последовательно. Оно начинается с построения стратегии управления бизнес-процессами (см. статью Виктории Коняхиной и Вячеслава Грачева “Использование ARIS на этапе Стратегия бизнес-процессов” в настоящем выпуске журнала), создания в соответствии с ней моделей процессов верхнего уровня (рис.5), рассматривающих наиболее важные аспекты деятельности предприятия, их детализации на модели второго уровня либо на модели выбора сценариев процессов, описывающих группы сходных по назначению процессов, после чего возможно создание моделей различных сценариев конкретных бизнес-процессов и детализирующих их моделей других типов (подробнее об этом можно прочесть в уже упомянутой выше статье в статье Марии Каменновой, Олега Вишнякова и Ирины Дятловой “Процессо-ориентированное управление компанией”) с целью их последующего внедрения и контроллинга.

Рис.5. Пример модели процессов верхнего уровня

Одним из наиболее распространенных способов описания алгоритма выполнения того или иного конкретного процесса (или одного из возможных сценариев процесса) является модель в нотации EPC (Event-Driven Process Chain), позволяющая описать процесс в виде последовательности функций, инициируемых событиями, и событий, наступающих в результате выполнения функций, с возможными условными переходами и ветвлениями согласно определенным правилам, а также с объектами, описывающими исполнителей функций, документы, использующиеся или производящиеся при выполнении функций, а также информационные системы, их функции или группы (кластеры) функций. Именно подобный тип модели процесса, подлежащего реализации, и создается с помощью Oracle Business Process Architect (рис. 6).

Рис.6. Пример модели процесса в нотации EPC

В таблице 1 описаны значки, присутствующие на моделях EPC и соответст-вующие им объекты.

Табл.1. Обозначение объектов на моделях EPC

Обозначение Тип объекта

Событие, инициирующее процесс либо возникаюее в процессе его вы-полнения

Функция, выполняющаяся внутри процесса

Тип прикладной системы (сервиса)

Модель данных/кластер

Логическое правило

Требуемая\поддерживаемая функция информационной системы

Чаще всего при создании реализации процессов используются уже имеющиеся в компании Web-сервисы (если же это не так, их следует создать до реализации самого процесса – впрочем, создание Web-сервисов не является предметом данной статьи, да и на эту тему за последние пять лет появилось достаточно публикаций, к которым могут обратиться читатели, интересующиеся данным вопросом). Для создания SOA-ориентированного описания бизнес-процесса нужно выполнить импорт WSDL-описания Web-сервисов, использующихся в данном процессе, в базу данных ARIS с помощью соответствующего пункта меню Oracle Business Process Architect.

В результате импорта WSDL-описания Web-сервисов, использующихся в данном процессе, в базу данных ARIS для каждого сервиса будет получен объект типа Application System Type (рис. 7).

Рис.7. Импортированный Web-сервис

WSDL(Web Services Description Language) представляет собой основанный на XML язык описания интерфейса для доступа к Web-сервису. Подобное описание содержит всю информацию, необходимую для доступа к данному сервису. Язык WSDL появился в результате объединения двух технологий: Network Accessible Service Specification Language (NASSL) фирмы IBM и Service Description Language (SDL) фирмы Microsoft. Спецификация WSDL находится по адресу: http://www.w3.org/TR/wsdl/. С точки зрения WSDL-документа Web-сервис представляет собой коллекцию портов, которые, в свою очередь, являются коллекцией абстрактных операций и сообщений. Абстракция операций и сообщений позволяет связывать их с различными протоколами и форматами данных типа SOAP, HTTP GET/POST или MIME.

Существующие средства для создания и использования Web-сервисов выпол-няют всю рутинную работу по генерации и обработке WSDL-документов, поэтому создание и обработка таких документов вручную требуется в крайне редких случаях. WSDL-документы активно используются средствами разработки для генерации прокси-кода, который может выполнять роль переходника между высокоуровневым кодом потребителя Web-сервиса и низкоуровневой реализацией отсылки сообщений для вызова методов Web-сервиса и получения результатов работы этих методов.

Далее следует связать полученные объекты типа Application System Type, соответствующие различным сервисам, с кластерами функций информационных систем (то есть опосредованно — с теми функциями модели EPC, которые их используют). В результате получится SOA-ориентированная модель подлежащего реализации процесса (рис. 8).

Рис.8. SOA-ориентированная модель подлежащего реализации процесса

На основе созданной модели Oracle Business Process Architect позволяет автоматически сгенерировать модели другого типа — BPEL process для описания самого технического процесса (рис. 9) и BPEL allocation diagram для описания взимодействия с интерфейсами Web-сервисов (рис. 10).

Рис. 9. Модель BPEL process для описания процесса, подлежащего реализации

Рис. 10. Модель BPEL allocation diagram для описания взаимодействия с интерфейсами Web-сервисов

В таблице 2 описаны значки, присутствующие на моделях BPEL process и BPEL allocation diagram и соответствующие им объекты.

Табл.2. Обозначение объектов на моделях BPEL process и BPEL allocation diagram

Обозначение Тип объекта

Функция, выполняющаяся внутри процесса и операция интерфейса Web-сервиса

Экземпляр объекта дан-ных (переменная), созда-ваемый внутри приложения или Web-сервиса

Partner Link – “коммуни-кационная” ссылка на используемый Web-сервис

Интерфейс используемо-го Web-сервиса

Событие, инициирующее процесс либо возникающее в процессе его вы-полнения

Модель BPEL process с помощью соответствующего пункта контекстного меню модели следует сохранить в виде набора XML-файлов, включающих BPEL-описание реализуемого процесса и WSDL-описания интерфейсов, экспортируемых или используемых данным процессом (они могут содержать ссылки на WSDL-описания сервисов, с которыми были связаны кластеры функций информационных систем SOA-ориентированной модели EPC процесса). Кроме того, если дальнейшая реализация процесса будет производиться с помощью Oracle JDeveloper, следует сгенерировать BPEL-описание для развертывания (deployment descriptor file), содержащее ссылки на местоположение WSDL-описаний Web-сервисов, к которым будет обращаться процесс.

3.6 Реализация процесса в Oracle JDeveloper и его развертывание

На основании сгенерированных с помощью Oracle Business Process Architect BPEL- и WSDL-описаний можно создать реализацию процесса с помощью средства разработки приложений Oracle JDeveloper, для чего в его среде разработки создается новый проект типа BPEL Process Project для реализации процесса и к нему добавляются сгенерированные выше описания (рис. 11).

Рис. 11. Проект реализуемого процесса в JDeveloper

Отметим, что для реализации процесса следует произвести дополнительные действия, например, добавить недостающие переменные и описать условия для логических переходов. Рекомендуется также сгенерировать Web-приложение для тестирования созданного процесса. После этого можно осуществить развертывание процесса согласно документации JDeveloper (напомним, что для его выполнения потребуются Oracle Application Server и Oracle BPEL Process Manager Server) и протестировать его работу.

Рис. 12. Тестирование реализованного процесса

4 Заключение

Итак, мы видим, что Oracle Business Process Analysis Suite позволяет не только моделировать, оптимизировать и публиковать бизнес-процессы, но и генерировать необходимые фрагменты проектов для их программной реализации на основе использующихся в компании Web-сервисов. Реализация подобных процессов при наличии готовых Web-сервисов оказывается значительно проще, чем часто применяемый сегодня процесс перенастройки бизнес-приложений (или даже переписывания их кода), и позволит ИТ-службам компаний быстрее реагировать на изменения в ее бизнес-процессах, позволяя сократить столь болезненный для многих компаний разрыв между требованиями бизнеса и их ИТ-поддержкой.

Хотя переход к применению Web-сервисов и архитектуре SOA, безусловно, потребует поначалу преодоления присущего многим руководителям консерватизма, применение Oracle Business Process Analysis Suite позволит в конечном итоге существенно повысить эффективность управления процессами тем компаниям, ИТ-инфраструктура которых основана на применении решений на основе Oracle Fusion Middleware.

Список использованной литературы: